The present invention relates to message brokering. Illustrative embodiments relate to, but not exclusively to, a message brokering system operable to implement a transaction recovery process.
Transaction processing systems are used to manage transactions in which an instructing party desires that an action be performed, often remotely, by at least one further party. In order for a transaction to take place between the parties, the instructing party provides a message to the further party requesting that the desired action be performed. In addition to the further party receiving the request to perform a desired action, the transaction process usually also entails a response, such as a message, being sent from the further party to the instructing party either to confirm that the action has been, or will be, completed, or to state that the transaction request has failed and/or why the desired action has failed.
An example of an action that might be performed as part of a transaction includes the case where a first party instructs a second party to request authorization of a payment from a third party. It is interesting to note that both the number and the importance of such transactions involving third parties, particularly in respect of those involving financial or commercial transactions, have increased enormously since the advent of inexpensive and readily-available networked electronic systems. In particular, growth in the use of such transactions is in large part attributable to the growth in Internet use for electronic commerce, where a user will typically buy a product on-line from a retailer by providing personal details to the retailer who will subsequently use the services of another party, such as a bank or credit card company, to authorize a payment for the product before it can be shipped to the user.
Where financial transactions are processed using the Internet, certain disadvantages may manifest themselves. In certain systems in which transactions are received from the Internet and then processed by a banking system, the danger exists of the banking system receiving repeat identical requests to process the same transaction. This may happen if a response to a message request indicating that the message request has been dealt with is delayed or lost in transmission from the banking system to the instructing party, subsequently causing the instructing party to issue repeat requests. An added danger also exists that the banking system may perform a transaction, such as, for example, crediting a retailer account and debiting a user account, more than once under the instruction of one or more repeat requests.
However, even if the banking system is configured to filter repeat requests, it is possible that such repeat requests will be generated which will bypass the filter mechanism if the banking system goes off-line, for example following events such as a system crash or during an administrative process. In this case incomplete transactions may still be in the banking system when it goes off-line. For this reason following a system crash, or during an administrative process, the banking system will often be taken completely off-line or be forced to enter a recovery mode to deal with any incomplete transactions. Where this happens, users of the system may find a delayed service, or even no service at all, without being aware of when or if their transaction request is going to be processed. This may in turn cause the users to wait in ignorance or even to resubmit a transaction for processing. Both of these scenarios are undesirable, with the latter being particularly so as the user may find they have submitted more than one valid request for the same transaction, and once the banking system goes back on-line both these transactions may be processed as they may not be deemed to be the same request by any repeat request filter mechanism.